원본 항목: Part 5. 코드 오류 — 8. 코드 정확성: 스레드 조기 종료CWE-730repo 폴더: sd50_threadexit/ (빌드·실행은 §3-1)
목표 시간: 1회차 12분 / 2회차 7분 / 3회차 5분
**실제 pthread**를 사용한다.
다만 “스레드가 회수됐는가”를 OS 자원 소진까지 기다리지 않고 즉시 확인할 수 있도록, 생성·회수 시점마다 직접 세는 카운터(g_unreaped)를 함께 둔다.
이 드릴의 문서 구성 (SD01~SD58 공통)
① 요구사항서 — 어떤 코드가 뚫려 있고, 무엇을 만드나.
② pseudo code 템플릿 — Bad 와 Good 의 뼈대이고, 회차마다 가린다.
③ 테스트 코드 — 공격은 막히고 정상은 통과해야 끝이다.
④ 자주 하는 실수
⑤ 모범답안 — 맨 뒤에 접어 둔다.
변형 A/B/C 는 같은 치환 규칙을 다른 소재로 다시 치는 것이다.
0. 이 드릴로 체화할 것
pthread_t th; if (pthread_create(&th, NULL, worker, result) != 0) return -1; g_unreaped++;- return 0; /* join/detach 없이 부모 종료 -> 자원 미회수 */+ pthread_join(th, NULL); /* 즉시 회수 */+ g_unreaped--;+ return 0;
스레드는 만드는 순간 “join할 것인가 detach할 것인가”를 반드시 함께 결정해야 한다.
결정을 안 하는 것 자체가 결함이다.
회차별 진행
회차
변형
보는 것
순서
1회차
A 백그라운드 작업 스레드 생성
① 요구사항서 ② pseudo code 전체
1. Bad 를 그대로 쳐서 취약점을 관찰한다. 2. Good pseudo 를 한 줄씩 코드로 바꾼다. 3. ③ 테스트를 실행한다.
2회차
Bpthread_detach로 회수하는 버전으로 변형
① 요구사항서 ② pseudo code 의 번호와 제목만 (Level 2)
1. Bad 를 치고 취약점을 확인한다. 2. 번호만 보고 Good 을 쓴다. 3. ③ 테스트를 실행한다.
3회차
C 여러 스레드를 반복 생성하는 루프로 확장
① 요구사항서만
1. ③ 테스트를 먼저 읽는다. 2. 백지에서 Bad 부터 Good 까지 재현한다.
1회차에 막히면 같은 변형을 한 번 더 친다.
3회차를 통과하면 A 를 백지로 다시 친다.
1. 요구사항서
1-A. 변형 A — 백그라운드 작업 스레드 생성
작업을 처리할 워커 스레드를 생성한다.
생성한 스레드는 반드시 join 또는 detach로 회수 여부가 결정돼야 한다.
결과값은 필요하면 안전하게 받아올 수 있어야 한다.
함수
int unreaped_count(void);void reset_unreaped(void);int spawn_worker_bad(int *result);int spawn_worker_good(int *result);
신뢰 경계
값
출처
검증 없이 흘러가는 곳
(해당 없음)
—
join/detach 결정 누락 자체가 결함이다
공격 입력표
상황
Bad 결과
이유
spawn_worker_bad() 호출
미회수 스레드 카운트가 1로 남음
pthread_join도 pthread_detach도 호출하지 않아 스레드 자원의 운명이 결정되지 않은 채 함수가 끝난다
같은 상황(Good)
미회수 카운트가 0으로 복귀, 결과값도 확실히 반영됨
pthread_join으로 완료를 기다린 뒤 회수한다
1-B. 변형 B — pthread_detach로 회수하는 버전으로 변형
결과를 기다릴 필요가 없는 “fire-and-forget” 워커라면 pthread_join 대신 pthread_attr_setdetachstate(PTHREAD_CREATE_DETACHED)나 생성 직후 pthread_detach(th)로 회수하는 함수를 만들어, “기다리지 않고도 회수는 확실히 한다”는 또 다른 표준 패턴을 익힌다
1-C. 변형 C — 여러 스레드를 반복 생성하는 루프로 확장
워커를 5개 연속 생성하는 함수를 만들어, Bad 버전은 unreaped_count()가 5까지 누적되고 Good 버전은 매번 0으로 돌아오는 것을 반복 확인한다
2. pseudo code 템플릿 — 보고 쳐서 익힌다
사용법
변형별로 아래 pseudo code 를 소스 파일에 주석만 복사한다.
코드는 주석을 보고 내가 쓴다.
다 쓰면 [ ] 를 x 로 바꾼다.
막히면 §5 모범답안(A)의 해당 단계만 본다.
2-A. spawn_worker_good — Level 1 (1회차, 전부 본다)
먼저 Bad 를 그대로 쳐서 §3 의 test_bad_is_vulnerable 이 통과하는지(= 실제로 뚫리는지) 확인한다.
그다음 Good 을 쓴다.
int spawn_worker_good(int *result){ /* 아무것도 안 본다. * §1 요구사항서와 §0 의 치환 규칙만 보고 친다. * * 막히면 아래만 찾아본다. * - `pthread_create` 직후에 join 할지 detach 할지 **같이** 결정 * - `-pthread` 링크 (Makefile 의 `LDLIBS`) */}
막혔을 때 찾는 순서
컴파일 에러가 나면 에러 문구를 본다.
unknown type name / implicit declaration 이면 include 누락이다.
man 3 <함수> 를 연다.
SYNOPSIS 맨 위의 #include 를 확인한다.
로직이 막히면 §3 테스트의 기대값을 먼저 읽는다.
공격 입력표(§1)와 테스트가 답이다.
#include <stdio.h>#include "threadexit.h"static int g_fail = 0;#define T_TRUE(cond, msg) \ do { if (!(cond)) { g_fail++; \ printf(" X %s:%d %s\n", __func__, __LINE__, msg); } } while (0)static int g_result_bad;static int g_result_good;static void test_bad_leaves_thread_unreaped(void){ reset_unreaped(); T_TRUE(spawn_worker_bad(&g_result_bad) == 0, "스레드 생성 자체는 성공해야 한다"); T_TRUE(unreaped_count() == 1, "Bad는 join도 detach도 하지 않아 생성한 스레드가 회수되지 않은 채로 남아야 한다(취약점 재현)");}static void test_good_reaps_thread(void){ reset_unreaped(); T_TRUE(spawn_worker_good(&g_result_good) == 0, "스레드 생성과 join이 모두 성공해야 한다"); T_TRUE(unreaped_count() == 0, "Good은 join으로 즉시 회수해 미회수 카운트가 0이어야 한다"); T_TRUE(g_result_good == 42, "join으로 완료를 기다렸으므로 워커의 결과가 반영돼 있어야 한다");}int main(void){ test_bad_leaves_thread_unreaped(); test_good_reaps_thread(); printf(g_fail ? "FAIL %d\n" : "PASS\n", g_fail); return g_fail ? 1 : 0;}
g_result_bad가 왜 전역 변수인가
Bad는 스레드를 회수하지 않으므로, 테스트 함수가 반환한 뒤에도 워커 스레드가 계속 실행 중일 수 있다.
결과를 담을 변수가 지역 스택 변수라면 함수가 끝난 뒤 워커가 그 자리에 늦게 쓰기를 시도하면서 이미 사라진 스택 메모리에 접근하는 또 다른 버그(SD47과 같은 종류)가 생길 수 있다.
그래서 g_result_bad는 프로세스가 끝날 때까지 유효한 전역 변수로 뒀다 — Bad 자체의 문제(미회수)와 그로 인한 2차 문제(댕글링 접근)를 뒤섞지 않기 위해서다.
눈여겨볼 점: spawn_worker_bad와 spawn_worker_good은 pthread_create 호출까지 완전히 동일하다.
차이는 그다음 pthread_join 한 줄의 유무뿐이다 — 스레드를 “만드는 것”과 “책임지고 회수하는 것”은 별개의 결정이라는 걸 보여준다.